Are you technically deprecating the FileConverterType with this change since the buffered stream does not look like you can pass custom converters?

NIT: one last thing: would it make sense to change the default value for the convertor in the get_stream method to the buffered version so the deprecation messages do not fire twice/ clean up the method easily? This is for this workflow.

Are you technically deprecating the FileConverterType with this change since the buffered stream does not look like you can pass custom converters?

Sort of. I think the way it is written is a bit incorrect (yielding a file constantly is very odd in my view) but the main idea of yielding an entire file is correct.

The Export_Task code is very over engineered and buggy and needs to be simplified.

We should aim to give customers basically 3 outputs: fully outputted in memory, line by line in memory, or an entire file by disk and that's it.

Allowing for a lot of customization such as choosing what chunk to export at (offset) or line makes etc. just makes our life more difficult maintaining the SDK.

NIT: one last thing: would it make sense to change the default value for the convertor in the get_stream method to the buffered version so the deprecation messages do not fire twice/ clean up the method easily? This is for this workflow.

No. BufferedJsonOutput has a schema of { json: any } versus { json_str: str }. Changing the convertor is a potential breaking change.

This is also why buffered_stream was introduced.